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Real party in interest 

Asset Reliance, Inc. (dba Asset Trust, Inc.) 

Related appeals 

An appeal for U.S. Patent Application 09/761,670 filed January 18, 2001 may be affected or have a 
bearing on this appeal. 

Status of Claims 

Claim 45, claim 46, claim 48, claim 49, claim 50, claim 51, claim 52, claim 54, claim 55, claim 56, 
claim 57, claim 58, claim 59, claim 66, claim 68, claim 69, claim 70, claim 72, claim 73, claim 74, 
claim 75, claim 76, claim 78, claim 79, claim 80 and claim 81 are rejected and are the subject of 
this appeal. Claims 44, 47, 53, 65, 67, 71 and 77 are amended. Claims 1 through 43 and 60 
through 64 were previously cancelled without prejudice. Claim 82 is withdrawn because of a 
restriction requirement. 

Status of Amendments 

An Amendment/Reply containing the amendments to claims 44, 47, 53, 65, 67, 71 and 77 was 
submitted on November 30, 2007. 

Summary of Claimed Subject Matter 

One embodiment of a method of and system for analyzing, modeling and valuing elements of a 
business enterprise according to the present invention is best depicted in Figures 1 - 15 of the 
specification for the instant application. Figure 1 gives an overview of the major processing steps 
which include converting and storing data from a plurality of database management systems for 
use in analysis, analyzing the data as required to: optionally value growth options, identify value 
drivers by element of value, develop a predictive model for each component of enterprise value 
and value the elements of value. 

Independent Claim 44 - One embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 44 where an article of 
manufacture guides the conversion and storage of data aggregated from a plurality of 
management systems in accordance with a common schema. The aggregated data are then used 
to develop a model of enterprise cash flow by element of value and component of value. The 
model of enterprise cash flow by element and component of value is then used to determine the 
current operation value of one or more elements of value. More specifically, data from the 
database management systems associated with a plurality of enterprise transaction systems are 
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aggregated and stored in one or more tables or files in accordance with a network schema as 
described FIG. 1 reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference 
numbers 221 - 223, 225 - 230, FIG. 10 reference numbers 710 - 1 through 710 - n, 720-1 
through 720 - n and 730 and line 16, page 18 through line 16, page 35 of the specification. The 
aggregated data are then analyzed using a series of models in order to identify the attributes of 
each element of value that contribute to the value of each component of value and identify sub- 
elements of value for each element of value. The identified attributes are then used to develop 
element and sub-element of value impact summaries in accordance with the procedure detailed in 
FIG. 6A reference number 302 - 305, 306 - 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B 
reference numbers 312 - 315, 325, 330, 335, 340, 345, 350 and 355, FIG. 6C reference numbers 
319, 321 - 323, 326 - 329, 332 and 375 , FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 
309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6E reference numbers 352 - 354, 315, 325, 330, 
335, 340, 345, 350 and 355, and line 15, page 35 through line 14, page 53 of the specification. 
The capitalized value of the components of value and the current operation are then determined as 
shown in FIG. 8 reference number 503 - 512, 514 and 515 and line 18, page 56 through Iine15, 
page 59 of the specification. The previously identified element of value impact summaries are then 
used as inputs to neural network models of the components of value (revenue, expense and 
capital change) as described in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 604, 625 and 
630, FIG. 9B reference numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, FIG. 9C 
reference 325, 330, 335, 340, 611, 613, 614, 625 and 630 and line 16, page 59 through line 5, 
page 62 of the specification. The weights from the neural network models are then used to 
determine the percentage of each component of value that is caused by the impact of each 
element of value before the percentages are combined with the capitalized values of the 
components of value to determine the current operation value contribution of each element of 
value as described in FIG. 12 reference number 772 - 782 and line 7, page 62 through line 25, 
page 65 of the specification. The models used to determine the value impact of each element of 
value are also use for: predicting an impact of a change to one or more elements of value on 
enterprise cash flow, identifying a set of changes to one or more elements of value that will 
optimize enterprise cash flow and producing financial statements that identify value and value 
changes by element of value. 

Dependent claims 

The limitations associated with dependent claim 45 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

The limitations associated with dependent claim 46 are described in several places including 
line 16, page 56 through line 9, page 59 of the specification. 

The limitations associated with dependent claim 48 are described in line 1, page 26 through line 
14, page 26. 
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The limitations associated with dependent claim 49 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 50 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 51 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 52 are described in a variety of places including 
FIG. 10. 

Independent Claim 53 - A second embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 53 where a process converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
schema. The aggregated data are then used to develop a model of enterprise cash flow by 
element of value and component of value that is used to calculate the current operation value 
contribution for each element of value. More specifically, data from the database management 
systems associated with a plurality of enterprise transaction systems are aggregated and stored in 
one or more tables or files in accordance with a network schema as described FIG. 1 reference 
number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference numbers 221 - 223, 225 - 
230, FIG. 10 reference numbers 710-1 through 710 - n, 720-1 through 720 - n and 730 and line 
16, page 18 through line 16, page 35 of the specification. The aggregated data are then analyzed 
using a series of models in order to identify the attributes of each element of value that contribute 
to the value of each component of value and identify sub-elements of value for each element of 
value. The identified attributes are then used to develop element and sub-element of value impact 
summaries in accordance with the procedure detailed in FIG. 6A reference number 302 - 305, 306 
- 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B reference numbers 312 - 315, 325, 330, 
335, 340, 345, 350 and 355, FIG. 6C reference numbers 319, 321 - 323, 326 - 329, 332 and 375 , 
FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 309, 325, 330, 335, 340, 345, 350 and 355, 
FIG. 6E reference numbers 352 - 354, 315, 325, 330, 335, 340, 345, 350 and 355, and line 15, 
page 35 through line 14, page 53 of the specification. The capitalized value of the components of 
value and the current operation are then determined as shown in FIG. 8 reference number 503 - 
512, 514 and 515 and line 18, page 56 through Iine15, page 59 of the specification. The previously 
identified element of value impact summaries are then used as inputs to neural network models of 
the components of value (revenue, expense and capital change) as described in FIG. 9A reference 
numbers 325, 330, 335, 340, 602 - 604, 625 and 630, FIG. 9B reference numbers 325, 330, 335, 
340, 605, 607, 608, 625 and 630, FIG. 9C reference 325, 330, 335, 340, 611, 613, 614, 625 and 
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630 and line 16, page 59 through line 5, page 62 of the specification. The weights from the neural 
network models are then used to determine the percentage of each component of value that is 
caused by the impact of each element of value before the percentages are combined with the 
capitalized values of the components of value to determine the current operation value contribution 
of each element of value as described in FIG. 12 reference number 772 - 782 and line 7, page 62 
through line 25, page 65 of the specification. The calculated values are then used to produce 
financial statements that include the calculated current operation values for the element of values 
as described in FIG. 13 reference number 802 - 806 and line 26, page 65 through line 32, page 
67. 

Dependent claims 

The limitations associated with dependent claim 54 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

The limitations associated with dependent claim 55 are described in several places including 
table 1, page 9, and Table 16, page 31 of the specification. 

The limitations associated with dependent claim 56 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 57 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 58 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 59 are described in several places including 
FIG. 10. 

Independent Claim 65 - A third embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 65 where a process converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
schema. The aggregated data are then used to develop a model of enterprise cash flow by 
element of value and component of value that is then used to identify and optimal set of changes to 
the elements of value. More specifically, data from the database management systems associated 
with a plurality of enterprise transaction systems are aggregated and stored in one or more tables 
or files in accordance with a network schema as described FIG. 1 reference number 200, FIG. 5A 
reference numbers 201 - 213, FIG. 5B reference numbers 221 - 223, 225 - 230, FIG. 10 reference 



Serial No: 08/999,245 



6 



numbers 710-1 through 710 - n, 720-1 through 720 - n and 730 and line 16, page 18 through 
line 16, page 35 of the specification. The aggregated data are then analyzed using a series of 
models in order to identify one or more performance indicators for each element of value that 
contribute to the value of each component of value and identify sub-elements of value for each 
element of value. The identified performance indicators are then used to develop element and 
sub-element of value impact summaries in accordance with the procedure detailed in FIG. 6A 
reference number 302 - 305, 306 - 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B reference 
numbers 312 - 315, 325, 330, 335, 340, 345, 350 and 355, FIG. 6C reference numbers 319, 321 - 
323, 326 - 329, 332 and 375 , FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 309, 325, 
330, 335, 340, 345, 350 and 355, FIG. 6E reference numbers 352 - 354, 315, 325, 330, 335, 340, 
345, 350 and 355, and line 15, page 35 through line 14, page 53 of the specification. The 
capitalized value of the components of value and the current operation are then determined as 
shown in FIG. 8 reference number 503 - 512, 514 and 515 and line 18, page 56 through Iine15, 
page 59 of the specification. The previously identified element of value impact summaries are then 
used as inputs to neural network models of the components of value (revenue, expense and 
capital change) as described in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 604, 625 and 
630, FIG. 9B reference numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, FIG. 9C 
reference 325, 330, 335, 340, 611, 613, 614, 625 and 630 and line 16, page 59 through line 5, 
page 62 of the specification. The component of value models are then optimized using genetic 
algorithms as described using reference numbers 325, 330, 335, 340, 345, 350 and 355 from FIG. 
6A to identify changes to the elements of value that will optimize performance. Cross referenced 
U.S. Patent 5,615,109 also describes an alternate method that could be used for identifying an 
optimal set of changes to the elements of value. 

Dependent claim 

The limitations and activities associated with dependent claim 66 are described in several 
places including FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 
and Table 16, page 31 of the specification. The activities comprise identifying a common set of 
attributes in a plurality of data dictionaries and aggregating data from a plurality of database 
management systems in accordance with said common attributes. 

Independent Claim 67 - A fourth embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 67 where an article of 
manufacture guides conversion and storage of event data from a plurality of management systems 
into an application database for use in processing. The aggregated data are then used to develop 
a model of enterprise cash flow by element of value and component of value that is used to 
forecast an impact of a response to an event. More specifically, data dictionaries from the 
database management systems associated with a plurality of enterprise transaction systems are 
obtained, relationships between the newly obtained data dictionaries and an application data 
dictionary are identified, these relationships are then used to guide the conversion and storage of 
data in one or more tables or files in accordance with a common schema in a common database 
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as described FIG. 1 reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B 
reference numbers 221 - 223, 225 - 230, FIG. 10 reference numbers 710-1 through 710 - n, 
720-1 through 720 - n and 730 and line 16, page 18 through line 16, page 35 of the specification. 
The aggregated data are then analyzed using a series of models in order to identify the attributes 
of each element of value that contribute to the value of each component of value and identify sub- 
elements of value for each element of value. The identified attributes are then used to develop 
element and sub-element of value impact summaries in accordance with the procedure detailed in 
FIG. 6A reference number 302 - 305, 306 - 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B 
reference numbers 312 - 315, 325, 330, 335, 340, 345, 350 and 355, FIG. 6C reference numbers 
319, 321 - 323, 326 - 329, 332 and 375 , FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 
309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6E reference numbers 352 - 354, 315, 325, 330, 
335, 340, 345, 350 and 355, and line 15, page 35 through line 14, page 53 of the specification. 
The capitalized value of the components of value and the current operation are then determined as 
shown in FIG. 8 reference number 503 - 512, 514 and 515 and line 18, page 56 through Iine15, 
page 59 of the specification. The previously identified element of value impact summaries are then 
used as to develop neural network models of the components of value (revenue, expense and 
capital change) as described in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 604, 625 and 
630, FIG. 9B reference numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, FIG. 9C 
reference 325, 330, 335, 340, 611, 613, 614, 625 and 630 and line 16, page 59 through line 5, 
page 62 of the specification. Event data are then input to the neural network models of cash flow 
by component of value as required to forecast an impact of one or more events on financial 
performance in a manner that is well known. An optimal response can be identified using the 
method detailed above for claim 65. 

Dependent claims 

The limitations associated with dependent claim 68 are described in several places including 
FIG. 10. 

The limitations associated with dependent claim 69 are described in several places including 
FIG. 10. 

The limitations associated with dependent claim 70 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

Independent claim 71 - A fifth embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 71 where a machine 
converts and stores data aggregated from a plurality of management systems in accordance with a 
common schema for use in processing. The aggregated data are then used to develop a model of 
enterprise cash flow by element of value and component of value. The model of enterprise cash 
flow by element and component of value is then used to determine the current operation value of 
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one or more elements of value. More specifically, data dictionaries from the database management 
systems associated with a plurality of enterprise transaction systems are obtained, relationships 
between the newly obtained data dictionaries and an application data dictionary are identified, 
these relationships are then used to guide the conversion and storage of data in one or more 
tables or files in accordance with a common schema in a common database as described FIG. 1 
reference number 200, FIG. 5A reference numbers 201 - 213, FIG. 5B reference numbers 221 - 
223, 225 - 230, FIG. 10 reference numbers 710-1 through 710 - n, 720-1 through 720 - n and 
730 and line 16, page 18 through line 16, page 35 of the specification. The aggregated data are 
then analyzed using a series of models in order to identify the attributes of each element of value 
that contribute to the value of each component of value and identify sub-elements of value for each 
element of value. The identified attributes are then used to develop element and sub-element of 
value impact summaries in accordance with the procedure detailed in FIG. 6A reference number 
302 - 305, 306 - 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6B reference numbers 312 - 
315, 325, 330, 335, 340, 345, 350 and 355, FIG. 6C reference numbers 319, 321 - 323, 326 - 329, 
332 and 375 , FIG. 6D reference numbers 337 - 339, 341 - 343, 305, 309, 325, 330, 335, 340, 345, 
350 and 355, FIG. 6E reference numbers 352 - 354, 315, 325, 330, 335, 340, 345, 350 and 355, 
and line 15, page 35 through line 14, page 53 of the specification. The capitalized value of the 
components of value and the current operation are then determined as shown in FIG. 8 reference 
number 503 - 512, 514 and 515 and line 18, page 56 through Iine15, page 59 of the specification. 
The previously identified element of value impact summaries are then used as inputs to neural 
network models of the components of value (revenue, expense and capital change) as described 
in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 604, 625 and 630, FIG. 9B reference 
numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, FIG. 9C reference 325, 330, 335, 340, 
611, 613, 614, 625 and 630 and line 16, page 59 through line 5, page 62 of the specification. The 
weights from the neural network models are then used to determine the percentage of each 
component of value that is caused by the impact of each element of value before the percentages 
are combined with the capitalized values of the components of value to determine the current 
operation value contribution of each element of value as described in FIG. 12 reference number 
772 - 782 and line 7, page 62 through line 25, page 65 of the specification. The models used to 
determine the value impact of each element of value are also use for: predicting an impact of a 
change to one or more elements of value on enterprise cash flow, identifying a set of changes to 
one or more elements of value that will optimize enterprise cash flow and producing financial 
statements that identify value and value changes by element of value. 

Dependent claims 

The limitations associated with dependent claim 72 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. It is well known to those of average skill in the art that the databases for the listed 
systems are typically relational database systems. 

The limitations associated with dependent claim 73 are described in several places including 
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FIG. 1, reference number 25 and line 15, page 12 through line 16 page 12 of the specification. 

The limitations associated with dependent claim 74 are described in several places including 
table 1, page 9, Table 16, page 31 and line 20, page 18 through line 14, page 26 of the 
specification. 

The limitations associated with dependent claim 75 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

The limitations associated with dependent claim 76 are described in several places including 
line 12, page 8 through line 22, page 8 of the specification. 

Independent claim 77 A sixth embodiment of the system for analyzing, modeling and valuing 
elements of a business enterprise is exemplified in independent claim 77 where a process converts 
and stores data aggregated from a plurality of management systems in accordance with a common 
schema for use in processing. The aggregated data are then used to develop a model of 
enterprise cash flow by element of value and component of value that is used to calculate the 
current operation value contribution for each element of value. More specifically, data dictionaries 
from the database management systems associated with a plurality of enterprise transaction 
systems are obtained, relationships between the newly obtained data dictionaries and an 
application data dictionary are identified, these relationships are then used to guide the conversion 
and storage of data in one or more tables or files in accordance with a common schema in a 
common database as described FIG. 1 reference number 200, FIG. 5A reference numbers 201 - 
213, FIG. 5B reference numbers 221 - 223, 225 - 230, FIG. 10 reference numbers 710 - 1 
through 710 - n, 720-1 through 720 - n and 730 and line 16, page 18 through line 16, page 35 of 
the specification. The aggregated data are then analyzed using a series of models in order to 
identify the attributes of each element of value that contribute to the value of each component of 
value and identify sub-elements of value for each element of value. The identified attributes are 
then used to develop element and sub-element of value impact summaries in accordance with the 
procedure detailed in FIG. 6A reference number 302 - 305, 306 - 309, 325, 330, 335, 340, 345, 
350 and 355, FIG. 6B reference numbers 312 - 315, 325, 330, 335, 340, 345, 350 and 355, FIG. 
6C reference numbers 319, 321 - 323, 326 - 329, 332 and 375 , FIG. 6D reference numbers 337 - 
339, 341 - 343, 305, 309, 325, 330, 335, 340, 345, 350 and 355, FIG. 6E reference numbers 352 - 
354, 315, 325, 330, 335, 340, 345, 350 and 355, and line 15, page 35 through line 14, page 53 of 
the specification. The capitalized value of the components of value and the current operation are 
then determined as shown in FIG. 8 reference number 503 - 512, 514 and 515 and line 18, page 
56 through Iine15, page 59 of the specification. The previously identified element of value impact 
summaries are then used as inputs to neural network models of the components of value (revenue, 
expense and capital change) as described in FIG. 9A reference numbers 325, 330, 335, 340, 602 - 
604, 625 and 630, FIG. 9B reference numbers 325, 330, 335, 340, 605, 607, 608, 625 and 630, 
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FIG. 9C reference 325, 330, 335, 340, 611, 613, 614, 625 and 630 and line 16, page 59 through 
line 5, page 62 of the specification. The weights from the neural network models are then used to 
determine the percentage of each component of value that is caused by the impact of each 
element of value before the percentages are combined with the capitalized values of the 
components of value to determine the current operation value contribution of each element of 
value as described in FIG. 12 reference number 772 - 782 and line 7, page 62 through line 25, 
page 65 of the specification. 

Dependent claims 

The limitations associated with dependent claim 78 are described in several places including 
FIG. 1, reference number 25 and line 15, page 12 through line 16 page 12 of the specification. 

The limitations associated with dependent claim 79 are described in several places including 
FIG. 1 , reference number 5 and line 20, page 12 of the specification. 

The limitations associated with dependent claim 80 are described in several places including 
FIG. 5A reference numbers 205, 206 and 207, table 1, page 9, Table 12, page 25 and Table 16, 
page 31 of the specification. 

The limitations associated with dependent claim 81 are described in table 1, page 9, Table 16, 
page 31 and line 20, page 18 through line 14, page 26 of the specification. 

Grounds of rejection to be reviewed on appeal 

Issue 1 - Whether claim 45, claim 46, claim 48, claim 49, claim 50, claim 51 and/or claim 52 are 
patentable under 35 USC 103(a) over U.S. Patent 4,989,141 (hereinafter, Lyons) with 
consideration to Database Management by Gordon C. Everest (hereinafter, Everest) ? 

Issue 2 - Whether claim 54, claim 55, claim 56, claim 57, claim 58 and/or claim 59 are patentable 
under 35 USC 103(a) over Lyons with consideration to Everest? 

Issue 3 - Whether claim 66 is patentable under 35 USC 103(a) over Lyons with consideration to 
Everest? 

Issue 4 - Whether claim 68, claim 69 and/or claim 70 are patentable under 35 USC 103(a) over 
Lyons with consideration to Everest? 

Issue 5 - Whether claim 72, claim 73, claim 74, claim 75 and/or claim 76 are patentable under 35 
USC 103(a) over Lyons with consideration to Everest? 

Issue 6 - Whether claim 78, claim 79, claim 80 and/or claim 81 are patentable under 35 USC 
103(a) over Lyons with consideration to Everest? 
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The Argument 



Grouping of Claims 

For each ground of rejection which Appellant contests herein which applies to more than one 
claim, such additional claims, to the extent separately identified and argued below, do not stand 
and fall together. 

Issue 1 - Whether claim 45, claim 46, claim 48, claim 49, claim 50, claim 51 and/or claim 52 
are patentable under 35 USC 103(a) over Lyons with consideration to Everest? 

The claims are patentable for several reasons. The primary reason is that the cited combination of 

documents and the arguments related to the cited combination fail to establish a prima facie case 

of obviousness in a number of ways for every rejected claim as detailed below. 

Reason #1 - The first reason claim 45, claim 46, claim 48, claim 49, claim 50, claim 51 and claim 
52 are patentable is that the proposed combination would destroy the ability of the inventions 
described by the cited documents to function . It is well established that: when a modification of a 
reference destroys the intent, purpose or function of an invention such a proposed modification is 
not proper and the prima facie cause of obviousness cannot be properly made (In re Gordon 733 
F.2d 900, 221 U.S.PQ 1125 Fed Circuit 1984). 

The Everest document teaches conventional database management systems . These conventional 
database management systems rely on logical data structures that enable enterprise wide data 
management with minimal redundancy. Everest lists the data structures used for conventional 
data storage in a taxonomy (page 46, Evidence Appendix). The key function of the Lyons 
invention is the four dimensional analysis of financial schedule data. The Lyons specification 
clearly states that the unconventional data storage method it uses is the key to enabling this type 
of analysis . Unlike conventional database management systems or worksheet applications, the 
Lyons invention allows for a four dimensional analysis of all financial data. In particular, the data 
stored in the system is organized into four business classifications or dimensions, namely 
Schedule, Entity, Period and Type (SEPT) (Lyons C4, L 17 - 23). This data storage method 
creates massive redundancy that provides some end-user benefits. Data is read from the 
datastore by various report and spreadsheet generating functions which convert data associated 
with particular SEPT values to desired output formats (Lyons, C2, L 58 - 61). Modifying the Lyons 
invention to use the conventional database management systems taught by Everest would destroy 
the ability of the report and spreadsheet generating functions to support a four dimensional 
analysis. In a similar manner, modifying the Everest database management systems to use the 
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unconventional Lyons method for data storage would destroy the ability of the Everest database 
management systems to support the enterprise wide management of all types of data without 
creating massive redundancy. 

Because the cited combination would destroy the ability of at least one of the cited inventions to 
function, the teachings of the documents are not sufficient to render the claims prima facie obvious . 

Reason #2 - The second reason claim 45, claim 46, claim 48, claim 49, claim 50, claim 51 and 
claim 52 are patentable is Reason #1 listed under issue #2. 

Reason #3 - The third reason claim 45, claim 46, claim 48, claim 49, claim 50, claim 51 and claim 
52 are patentable is that the cited combination would require a change in the end user control 
principle of operation in the Lyon invention. MPEP 2143.01 provides that when "the proposed 
modification or combination of the prior art would change the principle of operation of the prior art 
invention being modified, then the teachings of the references are not sufficient to render the 
claims prima facie obvious. In re Ratti, 270 F.2d 810, 123 USPQ 349 (CCPA 1959)". 

Consistent with its function of using four-dimensional financial data analysis to enable users to 
create reports, end-user control is one of the principles of operation of the Lyons invention . This 
principle dictated the development of a software package that includes features such as: 

a) User-controlled data dictionaries. Each data dictionary in the Lyons invention has the 
simplest possible function - it defines one type of data (Lyons, C7, L 62 - C8, L55). Lyons 
teaches that five (5) of these separate, simple, user-controlled data dictionaries are required for 
system operation (along with one optional data dictionary); 

b) High levels of data redundancy. The SEPT values defined by the user (see a above) are 
used to identify each piece of data that will be stored and processed by the Lyons invention 
(Lyons, C2, L 35 - 50, C4, L 20 - 43). As described in the Lyons specification, this method of 
data storage provides end user benefits but it also creates a massive redundancy in data 
storage; and 

c) \Jser-controlled data management. Consistent with its goal of providing user defined 
capabilities for creating reports, the Lyons invention provides each user with a number of 
functions for flexibly defining and managing the way stored data are organized. 

At the same time, the conventional database management systems described by Everest are 
designed to support hundreds of input screens, reports and files and thousands of data items. 
Because of this, the Everest system emphasizes comprehensive, centralized control in order to 
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maximize efficiency and stability. Everest specifically states that: "a shared database environment 
requires central control to coordinate the collection and use of data" (see page 43, Evidence 
Appendix). If the Lyons invention were modified to the incorporate centralized control principle 
taught by Everest, then the end-user control principle of operation of the Lyons invention would be 
changed. Alternatively, if the database management system of Everest were modified to utilize the 
end-user control principle of data management taught by Lyons, then the central control principle 
of operation of the Everest database management system would be changed. Because the cited 
combination requires a changes the principle of operation of at least one of the cited inventions, 
the teachings of the documents are not sufficient to render the claims prima facie obvious . 

Reason #4 - The fourth reason claim 45, claim 46, claim 48, claim 49, claim 50, claim 51 and claim 
52 are patentable is Reason #3 listed under issue #2. 

Reason #5 - The fifth reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 45, claim 46, claim 48, claim 49, claim 50, 
claim 51 and claim 52 is that the cited combination does not teach or suggest one or more of the 
limitations for every rejected claim. MPEP 2143.03 provides that: to establish prima facie 
obviousness of a claimed invention, all the claim limitations must be taught or suggested by the 
prior art (In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974)). Limitations not taught or 
suggested by the cited combination include: 

1) Claim 44 (affects all of the claims under this issue, affects claims 45, 51 and 52 directly). 
Limitations not taught or suggested include: 

a) using a series of models to identify one or more attributes for each of one or more elements of 
value that contribute to one or more components of value, 

b) creating a summary of the attributes for each element of value, 

c) developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, 

d) aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

e) predicting an impact of a change to one or more elements of value on enterprise cash flow, 

f) identifying a set of changes to one or more elements of value that will optimize enterprise cash 
flow, 

g) removing data associated with enterprise growth options, and 

h) using a series of models. 

As detailed below, Everest and Lyons both teach and rely on the use of a plurality of user- 
schemas in place of a common schema. Lyons also teaches away from the claimed analysis and 
modeling in a number of ways as detailed under reason #6. 
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2) Claim 46 (also affects claim 48 directly). Limitations not taught or suggested include a change 
in capital. 

3) Claim 52. Limitations not taught or suggested include a common network schema. 

Reason # 6 - The sixth reason that claim 45, claim 46, claim 48, claim 49, claim 50, claim 51 and 
claim 52 are patentable is that the cited combination fails to establish a prima facie case of 
obviousness because it teaches away from a number of claimed methods. MPEP § 2141.02 
states that: "in determining the difference between the prior art and the claims, the question under 
35 U.S.C. 103 is not whether the differences themselves would have been obvious but whether the 
claimed invention as a whole would have been obvious (Stratoflex, Inc. v. Aeroquip Corp., 713 
F.2d 1530, 218 USPQ 871 (Fed. Cir. 1983))." Furthermore, it is well established that: A prior art 
reference must be considered in its entirety, i.e., as a whole, including portions that would lead 
away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 
USPQ 303 (Fed. Cir. 1983), cert, denied, 469 U.S. 851 (1984). Examples of the cited combination 
teaching away from the claimed invention include: 

1) The claimed invention teaches the use of a series of models to identify: attributes for use in 
element of value modeling and a net contribution to cash flow for each element of value (see 
claim 44). Lyons teaches away from this approach in several ways: 

a) by teaching that the user - not a model or series of models - is responsible for identifying the 
relationships between the data being analyzed (Lyons, C27, L25 - 38); 

b) by limiting data storage after external processing to data that appears in a report format 
(Lyons, C2, L46 - 50); 

c) by limiting other programs to processing financial schedule data stored in the datastore (Lyons 
C20, L62-C21, L2); and 

d) by storing data in an unconventional manner that is designed to support spreadsheets and four 
dimensional data analysis (Lyons, C1, L 20 - C2, L 66). 

2) The claimed invention relies on the aggregation of data from a plurality of database 
management systems (see claim 44). Everest teaches away by relying on the use of a single, 
centrally controlled, database management system for an entire enterprise (Everest, page 37 see 
page 43, Evidence Appendix) "a shared database environment requires central control to 
coordinate the collection and use of data and to integrate the storage of data; 

3) The claimed invention teaches the development and use of a model of enterprise cash flow to 
identify a contribution and a value for elements of value such as brands, customers, employees, 
production equipment strategic partnerships and vendor relationships (see claim 44 and claim 
47). Lyons teaches away from this approach in several ways: 
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a) by teaching and relying on the use of data from balance sheets that value financial assets and 
tangible elements of value such as production equipment on a historical cost basis (a fact well 
known to those of average skill in the art); and 

b) by teaching and relying on the use of a balance sheet that does not include brands, customers, 
employees, strategic partnerships and vendor relationships (a fact well known to those of average 
skill in the art). 

4) The claimed invention teaches the use of a common schema (see claim 44). Everest and 
Lyons both teach and rely on the use of a plurality of user schemas. The userschema may use 
different data names, reflect a different data structure and refer to only portions of the 
database. . . . The userschema is the fundamental component of a DBMS architecture for achieving 
sharability and evolvability (page 44, Evidence Appendix and Lyons C7, L 62 - C8, L55); 

5) The claimed invention teaches the development and use of a model of enterprise cash flow by 
component of value and element of value (see claim 44 and claim 47). Lyons teaches away by 
teaching and relying on the use of a traditional cash flow statement that teach that the elements 
of value are not the source of cash flow (a fact well known to those of average skill in the art). 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. This failure 
provides additional evidence that the claimed invention for producing concrete, tangible and useful 
results is new, novel and non-obvious. 

Issue 2 - Whether claim 54, claim 55, claim 56, claim 57, claim 58 and/or claim 59 are 
patentable under 35 USC 103(a) over Lyons with consideration to Everest? 

The claims are patentable for several reasons. The primary reason is that the cited combination 

and the arguments related to the cited combination fail to establish a prima facie case of 

obviousness in a number of ways for every rejected claim as detailed below. 

Reason #1 - The first reason claim 54, claim 55, claim 56, claim 57, claim 58 and/or claim 59 are 
patentable is that the Examiner has not been able to explain the rationale for combining the 
Everest and Lyons teachings to replicate the functionality of the claimed invention. The Supreme 
Court in KSR noted that the analysis supporting a rejection under 35 U.S.C. 103 should be made 
explicit. The Court quoting In re Kahn 41 stated that '"[Rejections on obviousness cannot be 
sustained by mere conclusory statements; instead, there must be some articulated reasoning with 
some rational underpinning to support the legal conclusion of obviousness (KSR, 550 U.S. at I, 82 
USPQ2d at 1396)."' In particular, the Examiner has not explained why the conventional database 
management systems taught by Everest should be combined with the Lyons invention. The Lyons 
specification clearly states that conventional database management systems taught by Everest do 
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not support the four dimensional data analyses that the Lyons system was created to produce 



(Lyons C4, L 17-23) . 



Reason #2 - The second reason that claim 54, claim 55, claim 56, claim 57, claim 58 and/or claim 
59 are patentable is Reason #1 under issue #1 . 

Reason # 3 - The third reason claim 54, claim 55, claim 56, claim 57, claim 58 and claim 59 are 
patentable is that the combination of teachings described in the cited combination would force a 
change the data storage principle of operation of at least one of the inventions described in the 
cited documents. MPEP 2143.01 provides that when "the proposed modification or combination of 
the prior art would change the principle of operation of the prior art invention being modified, then 
the teachings of the references are not sufficient to render the claims prima facie obvious. In re 
Ratti, 270 F.2d 810, 123 USPQ 349 (CCPA 1959)". The Lyons invention was developed to allow 
end users to complete four dimensional analyses of financial data. The Lyons specification clearly 
states that the unconventional data storage methods it uses is the one of the principles of 
operation that enables this type of analysis . Unlike conventional data base management systems 
or worksheet applications, the Lyons invention allows for a four dimensional analysis of all financial 
data. In particular, the data stored in the system is organized into four business classifications or 
dimensions, namely Schedule, Entity, Period and Type (SEPT) (Lyons C4, L 17 - 23). This 
unconventional data storage method creates massive redundancy that provides some end-user 
benefits. Furthermore, the data input and output functions of the Lyons invention rely on these data 
storage principles to complete their defined functions. This method of data storage and retrieval is 
also particularly well suited to filling the cells in spreadsheets - one of the primary uses of the 
Lyons invention (Lyons, C1, L 20 - C2, L 66). By way of contrast, one of the principles of 
operation for the database management systems described by Everest is a reliance on a 
conventional data storage structure that can be used to manage data with minimal redundancy. 
Everest listed the data structures used for conventional data storage in a taxonomy (Everest page 
121, see page 46, Evidence Appendix). 

If the Lyons invention were modified to the incorporate the conventional data storage principle of 
operation taught by Everest, then a principle of operation of the Lyons invention would be changed. 
Alternatively, if the database management systems of Everest were modified to utilize the 
unconventional data storage principle of operation taught by Lyons, then a principle of operation of 
the Everest database management systems would be changed. Because the cited combination 
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requires a change in a principle of operation of at least one of the cited inventions, the teachings of 
the documents are not sufficient to render the claims prima facie obvious. 

Reason #4 - The fourth reason claim 54, claim 55, claim 56, claim 57, claim 58 and/or claim 59 are 
patentable is Reason #3 listed under issue #1 . 

Reason #5 - The fifth reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 54, claim 55, claim 56, claim 57, claim 58 
and/or claim 59 is that the cited combination does not teach or suggest one or more of the 
limitations for every rejected claim. MPEP 2143.03 provides that: to establish prima facie 
obviousness of a claimed invention, all the claim limitations must be taught or suggested by the 
prior art (In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974)). Limitations not taught or 
suggested by the cited combination include: 

1) Claim 53 (affects all of the claims under this issue, affects claims 54, 56, 57, 58 and 59 
directly). Limitations not taught or suggested include: 

a) using a series of models to identify one or more attributes for each of one or more elements of 
value that contribute to one or more components of value, 

b) creating a summary of the attributes for each element of value, 

c) developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, 

d) aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

e) predicting an impact of a change to one or more elements of value on enterprise cash flow, 

f) identifying a set of changes to one or more elements of value that will optimize enterprise cash 
flow, 

g) a network model of actual and forecast cash flow, 

h) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, 

i) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, with each subset being processed by a genetic algorithm independently 
of the others, 

j) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, with each subset being processed by a genetic algorithm independently 
of the others where a selective crossover produces a chromosome exchange between the 
subsets, 

k) the selective crossover occurs between two or more successive generations 
I) the removal of data associated with enterprise growth options, and 
m) using a series of models. 

As detailed below, Everest and Lyons both teach and rely on the use of a plurality of user- 
schemas. Lyons also teaches away from the claimed analysis and modeling in a number of ways 
as detailed under reason #6. 
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2) Claim 55. Limitations not taught or suggested include elements of value selected from the 
group consisting of brands, customers, employees, strategic partnerships and vendor 
relationships. It is well known to those of average skill in the art that the balance sheets 
manipulated by Lyons do not include the elements of value listed above. Everest has no relevant 
teachings. 

3) Claim 56. Limitations not taught or suggested include forecast event data and historical event 
data. 

4) Claim 59. Limitations not taught or suggested include a common network schema. 

Reason #6 - The sixth reason claim 54, claim 55, claim 56, claim 57, claim 58 and/or claim 59 are 
patentable is Reason #6 listed under issue #1 . 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. Taken 
together, these failures provide additional evidence that the claimed invention for producing 
concrete, tangible and useful results is new, novel and non-obvious. 

Issue 3 - Whether claim 66 is patentable under 35 USC 103(a) over Lyons with consideration 
to Everest? 

The claims are patentable for several reasons. One of the primary reasons is that the cited 
combination and the arguments related to the cited combination fail to establish a prima facie case 
of obviousness in a number of ways for every rejected claim as detailed below. 

Reason #1 - The first reason claim 66 are patentable is Reason #1 listed under issue #1 . 

Reason #2 - The second reason claim 66 is patentable is Reason #1 listed under issue #2. 

Reason #3 - The third reason claim 66 are patentable is Reason #3 listed under issue #1 . 

Reason #4 - The fourth reason claim 66 are patentable is Reason #3 listed under issue #2. 

Reason #5 - The fifth reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 66 is that the cited combination does not 
teach or suggest one or more of the limitations for every rejected claim. MPEP 2143.03 provides 
that: to establish prima facie obviousness of a claimed invention, all the claim limitations must be 
taught or suggested by the prior art (In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974)). 
Claims with limitations not taught or suggested by the cited combination include: 
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1) Claim 65 (also affects claim 66 directly). Limitations not taught or suggested include: 

a) using neural network models to identify one or more performance indicators for each of one or 
more elements of value, 

b) identifying one or more value drivers from said indicators, 

c) identifying one or more value drivers from said indicators and defining a contribution summary 
for each element of value for each component of value using said value drivers, 

d) creating a model of current operation financial performance by element and component of 
value using said contribution summaries, and 

e) simulating a current operation financial performance using said model as required to identify 
changes by element of value that will optimize one or more aspects of current operation financial 
performance 

f) automatically aggregating enterprise related event data from a plurality of database 
management systems into files or tables in a common database, and 

g) converting the data into a format that supports a common schema for analyzing and modeling 
an enterprise. 

2) Claim 66. Limitations and activities not taught or suggested include: 

a) using a common data dictionary to identify a common set of attributes in the enterprise related 
data from the plurality of database management systems, and 

b) identifying common attributes and automatically integrating data from a plurality of database 
management systems. 

Reason # 6 - The sixth reason that claim 66 is patentable is because the cited combination fails to 
establish a prima facie case of obviousness because it teaches away from a number of claimed 
methods. MPEP § 2141.02 states that: "in determining the difference between the prior art and the 
claims, the question under 35 U.S.C. 103 is not whether the differences themselves would have 
been obvious but whether the claimed invention as a whole would have been obvious (Stratoflex, 
Inc. v Aeroquip Corp., 713 F.2d 1530, 218 USPQ 871 (Fed. Cir. 1983))." Furthermore, it is well 
established that: A prior art reference must be considered in its entirety, i.e., as a whole, including 
portions that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlock, 
Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert, denied, 469 U.S. 851 (1984). Examples 
of the cited combination teaching away from the claimed invention include: 

1) The claimed invention teaches the use of a common schema (see claim 65). Everest and 
Lyons both teach and rely on the use of a plurality of user schemas. The userschema may use 
different data names, reflect a different data structure and refer to only portions of the 
database. . . . The userschema is the fundamental component of a DBMS architecture for achieving 
sharability and evolvability (page 44, Evidence Appendix and Lyons C7, L 62 - C8, L55); 

2) The claimed invention teaches the use of neural network models to identify: indicators for use 
in element of value modeling and a net contribution to current operation value for each element of 
value (see claim 65). Lyons teaches away from this approach in several ways: 
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a) by teaching that the user - not a model or series of models - is responsible for identifying the 
relationships between the data being analyzed (Lyons, C27, L25 - 38); 

b) by limiting data storage after external processing to data that appears in a report format 
(Lyons, C2, L46 - 50); 

c) by limiting other programs to processing financial schedule data stored in the datastore (Lyons 
C20, L62-C21, L2); and 

d) by storing data in an unconventional manner that is designed to support spreadsheets and four 
dimensional data analysis (Lyons, C1, L 20 - C2, L 66). 

3) The claimed invention relies on the aggregation of data from a plurality of database 
management systems (see claim 65). Everest teaches away by relying on the use of a single, 
centrally controlled, database management system for an entire enterprise (Everest, page 37, 
see page 43, Evidence Appendix) "a shared database environment requires central control to 
coordinate the collection and use of data and to integrate the storage of data"; 

4) The claimed invention teaches the conventional storage of data in files or tables (see claim 65 
and 66). Lyons teaches away by teaching and relying on an unconventional data storage method 
where all data associated with a particular Schedule, Entity, Period and Type (SEPT) are 
identified by a SEPT value and all data associated with a particular SEPT value are stored in a 
predetermined pattern relative to the SEPT value in a single, central datastore (Lyons, C2, L45 - 
50). Lyons teaches that this unconventional data storage method enables the four dimensional 
analysis of data. 

5) The claimed invention teaches the development and use of a model of current operation cash 
flow by component of value and element of value (see claim 65). Lyons teaches away by 
teaching and relying on the use of a traditional cash flow statement that teach that the elements 
of value are not the source of cash flow (a fact well known to those of average skill in the art). 

6) References provided by the Appellant (Rappaport) and the U.S.P.T.O. (Bielinski) teach away 
from the method of value driver identification and use incorporated in the claimed invention in a 
number of ways (see Evidence Appendix, pages 47 - 49 for a summary). 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. This failure 
provides additional evidence that the claimed invention for producing concrete, tangible and useful 
results is new, novel and non-obvious. 

Issue 4 - Whether claim 68, claim 69 and/or claim 70 are patentable under 35 USC 103(a) 
over Lyons with consideration to Everest? 

The claims are patentable for several reasons. One of the primary reasons is that the cited 



Serial No: 08/999,245 



21 



combination and the arguments related to the cited combination fail to establish a prima facie case 
of obviousness in a number of ways for every rejected claim as detailed below. 

Reason #1 - The first reason claim 68, claim 69 and/or claim 70 are patentable is Reason #1 listed 
under issue #1. 

Reason #2 - The second reason claim 68, claim 69 and/or claim 70 are patentable is Reason #1 
listed under issue #2. 

Reason #3 - The third reason claim 68, claim 69 and/or claim 70 are patentable is Reason #3 listed 
under issue #1. 

Reason #4 - The fourth reason claim 68, claim 69 and/or claim 70 are patentable is Reason #3 
listed under issue #2. 

Reason #5 - The fifth reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 68, claim 69 and/or claim 70 is that the cited 
combination does not teach or suggest one or more of the limitations for every rejected claim. 
MPEP 2143.03 provides that: to establish prima facie obviousness of a claimed invention, all the 
claim limitations must be taught or suggested by the prior art (In re Royka, 490 F.2d 981, 180 
USPQ 580 (CCPA 1974)). Claims with limitations not taught or suggested by the cited combination 
include: 

1) Claim 67 (also affects claims 68, claim 69 and 70 directly). Limitations not taught or suggested 
include: 

a) using a series of models to identify one or more attributes for each of one or more elements of 
value that contribute to one or more components of value, 

b) creating a summary of the attributes for each element of value, 

c) developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, 

d) aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

e) predicting an impact of a change to one or more elements of value on enterprise cash flow, 

f) identifying a set of changes to one or more elements of value that will optimize enterprise cash 
flow, 

g) a network model of actual and forecast cash flow, 

h) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, 

i) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
into a plurality of subsets, with each subset being processed by a genetic algorithm independently 
of the others, 

j) a network model of actual and forecast cash flow where the data being analyzed is partitioned 
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into a plurality of subsets, with each subset being processed by a genetic algorithm independently 
of the others where a selective crossover produces a chromosome exchange between the 
subsets, and 

k) where the selective crossover occurs between two or more successive generations 

1) removing data associated with enterprise growth options, 
m) using a series of models, 

n) identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

0) converting said data source data to a common schema by using said relationships in an 
application software segment, 

p) storing said converted event data in an application database for use in processing, 

q) forecast an impact of a response to one or more events from the plurality of events, and 

r) identify an optimal response to one or more events from the plurality of events 

2) Claim 68. Limitations not taught or suggested include a common schema that is defined by an 
application database schema. 

3) Claim 69. Limitations not taught or suggested include a common schema that further 
comprises a network schema. 

Reason # 6 - The sixth reason that claim 68, claim 69 and/or claim 70 are patentable is because the 
cited combination fails to establish a prima facie case of obviousness because it teaches away from 
a number of claimed methods. MPEP § 2141.02 states that: "in determining the difference 
between the prior art and the claims, the question under 35 U.S.C. 103 is not whether the 
differences themselves would have been obvious but whether the claimed invention as a whole 
would have been obvious (Stratoflex, Inc. v. Aeroquip Corp., 713 F.2d 1530, 218 USPQ 871 (Fed. 
Cir. 1983))." Furthermore, it is well established that: A prior art reference must be considered in its 
entirety, i.e., as a whole, including portions that would lead away from the claimed invention. W.L. 
Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert, 
denied, 469 U.S. 851 (1984). Examples of the cited combination teaching away from the claimed 
invention include: 

1) The claimed invention teaches the use of an application software segment to convert data (see 
claim 67). Everest teaches that the conversion of data is a database function (Everest page 409, 
see page 45, Evidence Appendix) "it is highly desirable for data conversion to be performed by 
the same underlying modules in the database control system"; 

2) The claimed invention teaches the use of a series of models to identify: attributes for use in 
element of value modeling and a net contribution to cash flow for each element of value (see 
claim 53/67). Lyons teaches away from this approach in several ways: 

a) by teaching that the user - not a model or series of models - is responsible for identifying the 
relationships between the data being analyzed (Lyons, C27, L25 - 38); 
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b) by limiting data storage after external processing to data that appears in a report format 
(Lyons, C2, L46 - 50); 

c) by limiting other programs to processing financial schedule data stored in the datastore (Lyons 
C20, L62-C21, L2); and 

d) by storing data in an unconventional manner that is designed to support four dimensional data 
analysis and spreadsheets (Lyons, C1 , L 20 - C2, L 66). 

3) The claimed invention relies on the aggregation of data from a plurality of database 
management systems (see claim 53/67). Everest teaches away by relying on the use of a single, 
centrally controlled, database management system for an entire enterprise (Everest, 37 see page 
45, Evidence Appendix) "a shared database environment requires central control to coordinate 
the collection and use of data and to integrate the storage of data"; 

4) The claimed invention teaches the use of a common schema (see claim 67). Everest and 
Lyons both teach and rely on the use of a plurality of user schemas. The userschema may use 
different data names, reflect a different data structure and refer to only portions of the 
database. . . . The userschema is the fundamental component of a DBMS architecture for achieving 
sharability and evolvability (page 44, Evidence Appendix and Lyons C7, L 62 - C8, L55); 

5) The claimed invention teaches the development and use of a model of enterprise cash flow by 
component of value and element of value. Lyons teaches away by teaching and relying on the 
use of a traditional cash flow statement that teach that the elements of value are not the source of 
cash flow (a fact well known to those of average skill in the art). 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. Taken 
together, these failures provide additional evidence that the claimed invention for producing 
concrete, tangible and useful results is new, novel and non-obvious. 

Issue 5 - Whether claim 72, claim 73, claim 74, claim 75 and claim 76 are patentable over 
Lyons with consideration to Everest? 

The claims are patentable for several reasons. One of the primary reasons is that the cited 
combination and the arguments related to the cited combination fail to establish a prima facie case 
of obviousness in a number of ways for every rejected claim as detailed below. 

Reason #1 - The first reason claim 72, claim 73, claim 74, claim 75 and/or claim 76 are patentable 
is Reason #1 listed under issue #1. 

Reason #2 - The second reason claim 72, claim 73, claim 74, claim 75 and/or claim 76 are 
patentable is Reason #1 listed under issue #3. 
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Reason #3 - The third reason claim 72, claim 73, claim 74, claim 75 and/or claim 76 are patentable 
is Reason #3 listed under issue #1. 

Reason #4 - The fourth reason claim 72, claim 73, claim 74, claim 75 and/or claim 76 are 
patentable is Reason #3 listed under issue #2. 

Reason #5 - The fifth reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 72, claim 73, claim 74, claim 75 and/or claim 
76 is that the cited combination does not teach or suggest one or more of the limitations for every 
rejected claim. MPEP 2143.03 provides that: to establish prima facie obviousness of a claimed 
invention, all the claim limitations must be taught or suggested by the prior art (In re Royka, 490 
F.2d 981, 180 USPQ 580 (CCPA 1974)). Claims with limitations not taught or suggested by the 
cited combination include: 

1) Claim 71 (affects claims 72, claim 73, claim 74, claim 75 and 76 directly). Limitations not taught 
or suggested include: 

a) analyzing data with a series of models to identify one or more attributes for each of one or 
more elements of value that impact one or more components of value and a value of the element 
of value 

b) analyzing data with a series of models to identify one or more attributes for each of one or 
more elements of value that impact one or more components of value and a value of the element 
of value and create a summary of said attributes, 

c) developing a model of an actual and a forecast enterprise cash flow by a component of value 
and element of value using said summaries, 

d) using the model to calculate a current operation value contribution for each of one or more 
elements of value, 

e) obtaining a plurality of data dictionaries and event data from a plurality of data sources via a 
network connection, 

f) identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

g) converting said data source data to a common schema by using said relationships in an 
application software segment, 

h) storing said converted event data in an application database for use in processing, 

i) predicting an impact of a change to one or more elements of value on enterprise cash flow, 

j) identifying a set of changes to one or more elements of value that will optimize enterprise cash 
flow, 

k) elements of value selected from the group consisting of brands, customers, employees, 
partnerships, vendor relationships and combinations thereof, 

1) modeling cash flow only after removing data associated with all enterprise growth options, and 
m) where the cash flow for each element of value by a component of value comprises a net cash 
flow comprised of an element of value contribution to each component of value net of its impact 
on one or more other elements of value. 

2) Claim 74. Limitations not taught or suggested include database management systems that are 
obtained from the group consisting of operation management systems, sales management 
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systems, human resource systems, accounts receivable systems, accounts payable systems, 
capital asset systems, inventory systems, invoicing systems, payroll systems, purchasing 
systems, an Intranet and combinations thereof. Everest teaches the use of a single database 
management system and does not mention an Intranet. Lyons teaches the use of data from 
systems that produce financial schedules (basic and advanced financial systems) and does not 
mention an Intranet. 

3) Claim 75. Limitations not taught or suggested include elements of value and components of 
value. 

4) Claim 76. Limitations not taught or suggested include the automated conversion of data. 

Reason # 6 - The sixth reason that claim 72, claim 73, claim 74, claim 75 and/or claim 76 are 
patentable is because the cited combination fails to establish a prima facie case of obviousness 
because it teaches away from a number of claimed methods. MPEP § 2141.02 states that: "in 
determining the difference between the prior art and the claims, the question under 35 U.S.C. 103 
is not whether the differences themselves would have been obvious but whether the claimed 
invention as a whole would have been obvious (Stratoflex, Inc. v. Aeroquip Corp., 713 F.2d 1530, 
218 USPQ 871 (Fed. Cir. 1983))." Furthermore, it is well established that: A prior art reference 
must be considered in its entirety, i.e., as a whole, including portions that would lead away from the 
claimed invention. W.L. Gore & Associates, Inc. v. Garlock, Inc., 721 F.2d 1540, 220 USPQ 303 
(Fed. Cir. 1983), cert, denied, 469 U.S. 851 (1984). Examples of the cited combination teaching 
away from the claimed invention include: 

1) The claimed invention teaches the use of an application software segment to convert data (see 
claim 71). Everest teaches that the conversion of data is a database function (see page 45, 
Evidence Appendix) "it is highly desirable for data conversion to be performed by the same 
underlying modules in the database control system"; 

2) The claimed invention teaches the use of a series of models to identify: attributes for use in 
element of value modeling and a net contribution to cash flow for each element of value (see 
claim 71). Lyons teaches away from this approach in several ways: 

a) by teaching that the user - not a model or series of models - is responsible for identifying the 
relationships between the data being analyzed (Lyons, C27, L25 - 38); 

b) by limiting data storage after external processing to data that appears in a report format 
(Lyons, C2, L46 - 50); 

c) by limiting other programs to processing financial schedule data stored in the datastore (Lyons 
C20, L62-C21, L2); and 

d) by storing data in an unconventional manner that is designed to support spreadsheets and four 
dimensional data analysis (Lyons, C1, L 20 - C2, L 66). 
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3) The claimed invention relies on the aggregation of data from a plurality of database 
management systems (see claim 71). Everest teaches away by relying on the use of a single, 
centrally controlled, database management system for an entire enterprise (Everest, page 37, 
see page 43, Evidence Appendix "a shared database environment requires central control to 
coordinate the collection and use of data and to integrate the storage of data') ; 

4) The claimed invention teaches the development and use of a model of enterprise cash flow to 
identify a contribution and a value for elements of value such as brands, customers, employees, 
production equipment strategic partnerships and vendor relationships (see claim 71). Lyons 
teaches away from this approach in several ways: 

a) by teaching and relying on the use of data from balance sheets that value financial assets and 
tangible elements of value such as production equipment on a historical cost basis (a fact well 
known to those of average skill in the art); and 

b) by teaching and relying on the use of a balance sheet that does not include brands, customers, 
employees, strategic partnerships and vendor relationships (a fact well known to those of average 
skill in the art). 

5) The claimed invention teaches the use of a common schema (see claim 71). Everest and 
Lyons both teach and rely on the use of a plurality of user schemas. The userschema may use 
different data names, reflect a different data structure and refer to only portions of the 
database. . . . The userschema is the fundamental component of a DBMS architecture for achieving 
sharability and evolvability (page 44, Evidence Appendix and Lyons C7, L 62 - C8, L55); 

6) The claimed invention teaches the development and use of a model of enterprise cash flow by 
component of value and element of value where the elements of value are brands, customers, 
employees, strategic partnerships and vendor relationships (see claim 71). Lyons teaches away 
by teaching and relying on the use of a traditional cash flow statement that teach that the 
elements of value are not the source of cash flow (a fact well known to those of average skill in 
the art). 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. Taken 
together, these failures provide additional evidence that the claimed invention for producing 
concrete, tangible and useful results is new, novel and non-obvious. 

Issue 6 - Whether claim 78, claim 79, claim 80 and claim 81 are patentable over Lyons with 
consideration to Everest? 

The claims are patentable for several reasons. One of the primary reasons is that the cited 
combination and the arguments related to the cited combination fail to establish a prima facie case 
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of obviousness in a number of ways for every rejected claim as detailed below. 

Reason # 1 - The first reason that claim 78, claim 79, claim 80 and/or claim 81 are patentable is 
Reason # 1 listed under issue #1 . 

Reason #2 - The second reason claim 78, claim 79, claim 80 and/or claim 81 are patentable is 
Reason #1 listed under issue #2. 

Reason #3 - The third reason claim 78, claim 79, claim 80 and/or claim 81 are patentable is 
Reason #3 listed under issue #1. 

Reason #4 - The fourth reason claim 78, claim 79, claim 80 and/or claim 81 are patentable is 
Reason #3 listed under issue #2. 

Reason #5 - The fifth reason that the cited combination fails to establish a prima facie case of 
obviousness that would support the rejection of claim 78, claim 79, claim 80 and/or claim 81 is that 
the cited combination does not teach or suggest one or more of the limitations for every rejected 
claim. MPEP 2143.03 provides that: to establish prima facie obviousness of a claimed invention, 
all the claim limitations must be taught or suggested by the prior art (In re Royka, 490 F.2d 981, 
180 USPQ 580 (CCPA 1974)). Claims with limitations not taught or suggested by the cited 
combination include: 

1) Claim 77 (also affects claims 78, claim 79, claim 80 and claim 81 directly). Limitations not 
taught or suggested include: 

a) analyzing data with a series of models to identify one or more attributes for each of one or 
more elements of value that impact one or more components of value and a value of the element 
of value, 

b) analyzing data with a series of models to identify one or more attributes for each of one or 
more elements of value that impact one or more components of value and a value of the element 
of value and create a summary of said attributes, 

c) developing a model of an actual and a forecast enterprise cash flow by a component of value 
and element of value using said summaries, 

d) using the model to calculate a current operation value contribution for each of one or more 
elements of value, 

e) obtaining a plurality of data dictionaries and event data from a plurality of data sources via a 
network connection, 

f) identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

g) converting said data source data to a common schema by using said relationships in an 
application software segment, 

h) storing said converted event data in an application database for use in processing, 

i) modeling financial performance only after removing data associated with all enterprise growth 
options, 
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j) a common network schema, 
k) a series of models, 

1) a plurality of data sources that comprise database management systems for a plurality of 
enterprise transaction systems, and 

m) identifying one or more changes by element of value that will optimize one or more aspects of 
current operation financial performance. 

2) Claim 78. Limitations not taught or suggested include a back-end interface that comprises a 
network connection. Everest teaches the use of a separate computer for a back-end interface. 

3) Claim 79. Limitations not taught or suggested include accessing, converting, integrating and 
storing data from an Internet. 

4) Claim 80. Limitations not taught or suggested include elements of value and components of 
value. 

5) Claim 81. Limitations not taught or suggested include database management systems that are 
obtained from the group consisting of operation management systems, sales management 
systems, human resource systems, accounts receivable systems, accounts payable systems, 
capital asset systems, inventory systems, invoicing systems, payroll systems, purchasing 
systems, an Intranet and combinations thereof. Everest teaches the use of a single database 
management system and does not mention an Intranet. Lyons teaches the use of data from 
systems that produce financial schedules (basic and advanced financial systems) and does not 
mention an Intranet. 

Reason #6 - The sixth reason claim 78, claim 79, claim 80 and/or claim 81 are patentable is 
Reason #6 listed under issue #5. 

Summarizing the above, the Appellant respectfully submits that the Examiner has failed to produce 
the evidence required to establish a prima facie case of obviousness for a single claim. Taken 
together, these failures provide additional evidence that the claimed invention for producing 
concrete, tangible and useful results is new, novel and non-obvious. 
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Conclusion 

As detailed above, the evidence used to support the rejection of the pending claims consists of a 
document combination that fails to support an prima facie case of obviousness for a single claim. 
For this reason and the reasons listed below, the Appellant respectfully but forcefully contends that 
each claim is patentable. 

The Appellant notes that with respect to the prosecution of the instant application, it appears that 
the U.S.P.T.O. has not fully complied with the requirements set forth in the APA and 35 USC 3. 
Among other things, the Appellant specifically notes that: 

a) There appears to have been numerous instances of non-compliance with MPEP 904.03; 

b) The prosecution of the instant application has been substantially delayed for a variety of 
reasons. At least part of the delay appears to have occurred because the Examiner refused to 
respond to reasonable requests for a copy of a missing office action; and 

c) The prior art review for the instant application appears to have been completed under a different 
standard than that used for the review and allowance of other, similar applications. 

The Appellant also notes that the same Examiner previously found similar claims to be allowable 
(see pages 58 - 59, Evidence Appendix). Since that time the Examiner has authored or signed 
Office Actions that provide substantial additional evidence documenting the novelty, non- 
obviousness and newness of the claimed invention. 

Therefore, reversal of all rejections is courteously solicited. 

Respectfully submitted, 
Asset Trust, Inc. 

/B.J. Bennett/ 

B.J. Bennett, President 
Dated: June 6, 2008 
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Claims Appendix 



44. A program storage device readable by a computer, tangibly embodying a program of 
instructions executable by at least one computer to perform a data method, the method 
comprising: 

aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

storing said aggregated data in one or more tables or files to support processing, 
analyzing at least a portion of said data with a series of models to identify one or more attributes 
for each of one or more elements of value that contribute to one or more components of value 
and create a summary of said attributes for each element of value, 

developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, and 
using the model to calculate a current operation value contribution for each of one or more 
elements of value and complete tasks selected from the group consisting of predicting an impact 
of a change to one or more elements of value on enterprise cash flow and identifying a set of 
changes to one or more elements of value that will optimize enterprise cash flow, produce 
financial statements that identify value and value changes by element of value and combinations 
thereof 

where the current operation value of each of one or more elements of value is reported in an 
enterprise balance sheet, 

where the enterprise cash flow is modeled only after removing data associated with all 
enterprise growth options, and 

where the predictive model is a model of actual and forecast cash flow. 

45. The program storage device of claim 44 wherein the enterprise related data are aggregated in 
accordance with a common data dictionary that identifies a common set of attributes selected from 
the group consisting of: category of value, component of value, element of value, currency, unit of 
measure and combinations thereof. 

46. The program storage device of claim 45, wherein the components of value are selected from 
the group consisting of revenue, expense, change in capital and combinations thereof. 

47. The program storage device of claim 44, wherein the elements of value are selected from the 
group consisting of brands, customers, employees, production equipment, strategic partnerships, 
vendor relationships and combinations thereof. 

48. The program storage device of claim 46, wherein at least part of enterprise-related data is 
entered for each point of time over a sequential series of points in time preceding a specified 
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valuation date. 

49. The program storage device of claim 48, wherein the enterprise related data further comprise 
forecast event data and historical event data. 

50. The program storage device of claim 49, wherein the enterprise related data further comprises 
transaction data. 

51. The program storage device of claim 44 wherein said plurality of database management 
systems are obtained from the group consisting of advanced financial systems, basic financial 
systems, operation management systems, sales management systems, human resource systems, 
accounts receivable systems, accounts payable systems, capital asset systems, inventory 
systems, invoicing systems, payroll systems, purchasing systems, the Internet and combinations 
thereof. 

52. The program storage device of claim 44, wherein the common schema further comprises a 
network model. 

53. A computer-implemented method, comprising: 

aggregating enterprise related data from a plurality of database management systems in 
accordance with a common schema, 

storing said aggregated data in one or more tables or files to support processing for enterprise 
analysis and modeling, 

analyzing at least a portion of said data with a series of models to identify one or more attributes 
for each of one or more elements of value that contribute to a value of the element of value and 
create a summary of said attributes, 

developing a model of enterprise cash flow by a component of value that identifies a net 
contribution to cash flow for each element of value using said summaries, 
using the model to calculate a current operation value contribution for each of one or more 
elements of value, and 

preparing and presenting an enterprise financial statement that includes a current operation value 

for each of one or more elements of value 
where the one or more elements of value comprise one or more intangible elements of value, 
where the one or more attributes for each of one or more elements of value further comprise 
one or more value drivers, 

where the enterprise cash flow is modeled only after removing data associated with all 
enterprise growth options, and 

where the predictive model is a network model of actual and forecast cash flow where the data 
being analyzed is partitioned into a plurality of subsets, with each subset being processed by a 
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genetic algorithm independently of the others and where a selective crossover produces a 
chromosome exchange between the subsets, and 

where the selective crossover occurs between two or more successive generations. 

54. The method of claim 53, wherein the enterprise related data are aggregated in accordance 
with a common data dictionary that identifies a common set of attributes selected from the group 
consisting of category of value, component of value, element of value, currency, unit of measure 
and combinations thereof. 

55. The method of claim 54, wherein one or more elements of value are selected from the group 
consisting of brands, customers, employees, production equipment, strategic partnerships, vendor 
relationships and combinations thereof. 

56. The method of claim 53, wherein enterprise related data further comprises forecast event data 
and historical event data. 

57. The method of claim 53, wherein the enterprise related data further comprises transaction 
data. 

58. The method of claim 53, wherein said plurality of database management systems are obtained 
from the group consisting of advanced financial systems, basic financial systems, operation 
management systems, sales management systems, human resource systems, accounts receivable 
systems, accounts payable systems, capital asset systems, inventory systems, invoicing systems, 
payroll systems, purchasing systems, the Internet and combinations thereof. 

59. The method of claim 53, wherein the common schema further comprises a network model. 

65. A computer-implemented method, comprising: 
automatically aggregating enterprise related event data from a plurality of database management 
systems into files or tables in a common database, thereby converting the data into a format that 
supports a common schema for analyzing and modeling an enterprise, 

using neural network models to identify one or more performance indicators for each of one or 
more elements of value, 

identifying one or more value drivers from said indicators and defining a contribution summary for 
each element of value for each component of value using said value drivers, 
creating a model of current operation financial performance by element and component of value 
using said contribution summaries, and 

simulating a current operation financial performance using said model as required to identify 
changes by element of value that will optimize one or more aspects of current operation financial 
performance 
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where the current operation financial performance is modeled only after removing data 
associated with all enterprise growth options, 

where the elements of value are selected from the group consisting of brands, customers, 
employees, intellectual capital, partners, vendors, vendor relationships and combinations 
thereof, and 

where the components of value are selected from the group consisting of revenue, expense, 
capital change and combinations thereof. 

66. The method of claim 65, the method further comprising: 

using a common data dictionary to identify a common set of attributes in the enterprise related 
data from the plurality of database management systems, the attributes including at least one 
of: component of value, currency, element of value, unit of measure, or a combination thereof; 
automatically aggregating the enterprise related data from the plurality of database 
management systems using the identified common set of attributes. 

67. A computer readable medium having sequences of instructions stored therein, which when 
executed cause the processor in at least one computer to perform an enterprise data integration 
and analysis method, comprising: 

obtaining a plurality of data dictionaries and event data from a plurality of data sources via a 
network connection, 

identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

converting said data source data to a common schema by using said relationships in an 
application software segment, 

storing said converted event data in an application database for use in processing, and 
analyzing said data using the enterprise cash flow model of claim 53 as required to forecast an 
impact of a response to one or more events from the plurality of events and optionally identify 
an optimal response to one or more events from the plurality of events 
where a plurality of data sources further comprise a plurality of database management 
systems for applications selected from the group consisting of a basic financial system, a 
human resource system, an advanced financial system, a sales system, an operations system, 
an accounts receivable system, an accounts payable system, a capital asset system, an 
inventory system, an invoicing system, a payroll system, a purchasing system and 
combinations thereof and 
where event data comprise transaction data. 

68. The computer readable medium of claim 67, wherein a common schema is defined by an 
application database schema. 
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69. The computer readable medium of claim 67, wherein a common schema further comprises a 
network schema. 

70. The computer readable medium of claim 67, wherein a common schema contains a common 
data dictionary where said common data dictionary defines common attributes selected from the 
group consisting of elements of value, components of value, currencies, units of measure, time 
periods, dates and combinations thereof. 

71. A financial system, comprising: 

a computer with a processor having circuitry to execute instructions; 

a storage device available to said processor with sequences of instructions stored therein, an 
interface coupled to a plurality of data sources each of which has a data dictionary, and an 
application software segment which when executed causes the processor to: 
obtain a plurality of data dictionaries and data from the plurality of data sources, 
identify one or more relationships between each data source data dictionary and an 
application database data dictionary, 

convert said data source data to a common schema by using said relationships, 

store said converted data in an application database for use in processing, 

analyzing at least a portion of said data with a series of models to identify one or more 

attributes for each of one or more elements of value that impact one or more components of 

value and a value of the element of value and create a summary of said attributes, 

developing a model of an actual and a forecast enterprise cash flow by a component of value 

and element of value using said summaries, and 

using the model to calculate a current operation value contribution for each of one or more 
elements of value and complete tasks selected from the group consisting of predicting an 
impact of a change to one or more elements of value on enterprise cash flow and identifying a 
set of changes to one or more elements of value that will optimize enterprise cash flow and 
combinations thereof 

where the one or more elements of value are selected from the group consisting of brands, 
customers, employees, partnerships, vendor relationships and combinations thereof, 
where the enterprise cash flow is modeled only after removing data associated with all 
enterprise growth options, and 

where the cash flow for each element of value by a component of value comprises a net 
cash flow comprised of an element of value contribution to each component of value net of 
its impact on one or more other elements of value. 

72. The system of claim 71 , wherein a plurality of data sources further comprise a plurality of 
relational databases that use different data formats. 
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73. The system of claim 71 , wherein an interface further comprises a network connection. 

74. The system of claim 71, wherein a plurality of data sources further comprise database 
management systems for applications selected from the group consisting of a basic financial 
system, a human resource system, an advanced financial system, a sales system, an operations 
system, an accounts receivable system, an accounts payable system, a capital asset system, an 
inventory system, an invoicing system, a payroll system,, a purchasing system, an intranet and 
combinations thereof. 

75. The system of claim 71, wherein a common schema contains a common data dictionary that 
defines common attributes selected from the group consisting of elements of value, components of 
value, currencies, units of measure, time periods, dates and combinations thereof. 

76. The system of claim 71, wherein a conversion of data to a common schema further comprises 
an conversion of data that is completed automatically. 

77. A computer implemented data method, comprising: 

accessing a plurality of enterprise data and data dictionaries via a back-end interface coupled to 
a plurality of data sources, 

identifying one or more relationships between each data source data dictionary and an 
application database data dictionary, 

converting said enterprise data to a common schema by using said relationships in an 
application software segment, and 

storing said converted data in an application database for use in processing, 
analyzing at least a portion of said data to create a plurality of network models that identify a 
contribution for each of one or more elements of value to one or more aspects of current 
operation financial performance using said data, 

using said models to calculate a current operation value contribution for each of one or more 

elements of value and to identify one or more changes by element of value that will optimize 

one or more aspects of current operation financial performance, and 

displaying the one or more identified changes 
where the one or more aspects of financial performance are selected from the group 
consisting of revenue, expense, capital change, cash flow and combinations thereof, 
where the aspects of financial performance are modeled only after removing data associated 
with all enterprise growth options, 

where a common schema further comprises a network schema, and 

where a plurality of data sources further comprise database management systems for a 

plurality of enterprise transaction systems. 

78. The method of claim 77, wherein a back-end interface further comprises a network connection. 
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79. The method of claim 77, wherein the method further comprises accessing, converting, 
integrating and storing data from an Internet. 

80. The method of claim 77, wherein a common schema further comprises a common data 
dictionary where said common data dictionary defines common attributes selected from the group 
consisting of elements of value, components of value, currencies, units of measure, time periods, 
dates and combinations thereof. 

81. The method of claim 77, wherein a plurality of enterprise transaction systems are selected 
from the group consisting of a basic financial system, a human resource system, an advanced 
financial system, a sales system, an operations system, an accounts receivable system, an 
accounts payable system, a capital asset system, an inventory system, an invoicing system, a 
payroll system, a purchasing system, an Intranet and combinations thereof. 
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Evidence Appendix 

Pages 39 - 45 excerpt from Everest document first submitted August 1 7, 2006 

Pages 46 - 48 declaration under Rule 1 32 first submitted November 5, 2007 

Pages 48-52 4 pages returned to file wrapper on April 8, 2006 

Pages 53 - 54 Petition-response dated August 27, 2004 

Page 55 Page from November 30, 2007 Amendment/Reply 

Page 56 Page from reference first submitted November 20, 2007 

Page 57 Page from reference first submitted November 30, 2007 

Pages 58 - 59 Notice of allowable subject matter from a November 21 , 2000 Office 
Action 
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36 liVERrsr: database manaohment 

An organization cannot simply acquire a DBMS, plug it in, and watch it run. A 
DBMS by itself has no data, no stored queries or report definitions, and no user 
application programs to act on that data. The organization must collect and store (or 
convert) data, must train users, and must develop report definitions and application 
processes to operate in the new database environment. 

As DBMSs become less costly, more comprehensive En capabilities, easier to use, 
and available on smaller systems (minicomputers and microcomputers), the counter- 
vailing forces diminish. In spite of the cost of a DBMS, an organization's need may be 
so overwhelming that waiting any longer would be an expensive mistake — as it be- 
comes increasingly expensive to develop new applications using obsolete tools and 
methods. 



2.4 OBJECTIVES OF DATABASE MANAGEMENT* 

Having considered the various factors which can motivate an organization to move 
toward the database approach and acquire a DBMS, what are the objectives to be 
accomplished with such a move? This section outlines the various objectives an organi- 
zation my have in moving to the database approach. 

Motivators are problems an organization faces while objectives are the desirable 
end results stemming from a solution to those problems. An expression of objectives 
serves to focus attention on the needs of the using environment and the system and 
administrative requirements for meeting those needs. Some objectives of database 
management derive directly from the assumed context of organizations and manage- 
ment information systems. 

The proper management of any resource involves making it available for its in- 
tended purpose and controlling its use so as to maintain its integrity, ensuring that it is 
used as intended and that it will be available for future use. Management implies both 
control and use. Database management encompasses the control and use of data re- 
sources in an organization. Control involves maintaining the existence and quality of 
the database and restricting its use to authorized people. Control seeks to maintain 
database integrity. Use of data resources leads to the objective of availability, which 
includes sharing present data resources and enhancing future availability. The objec- 
tives of sharability. availability, cvolvability, and integrity are related as shown in 
Figure 2-2. 

2.4.1 Sharability 

An ability to share data resources is a fundamental objective of database manage- 
ment. In its fullest interpretation, this means different people and different processes 
using the same actual data at virtually the same time. 

* An earlier version of the material in ihis chapter appeared in information Systems: COINS-IV, Proceed- 
ings of the Fourth fniernational Symposium on Computer and Information Sciences, Miami Beach, Florida, 
1972 December 14-16, edited hy Julius T, Tmi. New York: Plenum Press. !974, pages 1-35. Portions 
reprinted with permission. 
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Figure 2-2. Objectives of Database Management, 

The management of any resource involves both the use of that resource and the control of its use. 



No person in an organization can act completely independently of everyone else in 
the organization. An organization brings together a variety of human talents to work 
together toward common goals. In working toward goals, people perform various 
operations and activities in varying degrees of cooperation or conflict. A database, 
whether or not it can be identified as a single physical entity, contains daia relating lo 
the primary and support operations of an organization. Sharing of data is a necessary 
first step toward a corporate database. 

Since the data pertains to various aspects of the organization, it literally "be- 
longs" to the whole organization and not to any one individual. A system which 
provides shared access to a corporate database is quite different from a typical time- 
sharing system where files are "owned" by individual users.* In organizations, shared 
tiles are the general rule and private files become the exception. 

A shared database environment requires central control to coordinate the collection 
and use of data and to integrate the storage of data. This can result in increased 
consistency, reduced redundancy, and reduced effort in the capture and maintenance of 
data. 

Rather far reaching ramifications stem from the stated objective of sharability: 

• Serving different types of users with varying skill levels 

• Handling different user views of the same stored data 

• Combining interrelated data 

• Setting standards 

• Controlling concurrent updates so as to maintain data integrity 

• Coordinating restart and recover)' operations across multiple users 

This list indicates some of the additional problems which arise in managing shared 
data. A central implication of sharing is that compromise will often be required be- 



*The typical lime-sharing system in university or scientific research environments permits sharing rime 
on computer system resources. Time-sharing systems handle the private files of various participants in the 
environment, hach file has an owner, that is, a person who creates and maintains the file. Sometimes a 
person can use aula with permission of the owner, or use data in a small "public file," which is usually 
read-only. 
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Figure 3-10. Userschema: Definition of a User's View of Ihe Database. 

Every user has some perception of the .structure ind content of the data being accessed at any given 
lime. The userschema is a formal expression of ihe User's view of the database, ll consists of: 

• A logical daia definition. 

• Its physical representation in a program buffer, or on the screen or output page of a user's 

lerminat. 

• Its mapping to ihe data in the database. 

The userschema may use different data names, reflect a different data structure, and refer to only 
portions of the database. The DBMS knows both the userschema and the database schema and can convert 
lite dala when transferred between Lhe two according to the defined mapping. The userschema is the funda- 
mental component of a DBMS architecture for achieving sharabiiity and evolvability. 



Serial No.: 08/999,245 



43 



CHAPTER ELEVEN: DAT A iNOEPHNDENCE, DATA CONVERSION. AND DATABASE REVISION' 409 

As before, if the change to the schema only has an efficiency impact, il may be 
desirable to continue to execute the program with a fully defined userschema, omitting 
the fact that it was a copy of the fold") schema. The system would operate normally, 
testing for incompatibilities and performing any required conversions and transforma- 
tions. The less efficient execution would be an interim solution until the program could 
be rewritten as priority demands on the human resources would permit. Again, the 
central point is that the using organization has a choice, based purely on economic 
grounds — the cost of running inefficiently versus the cost of reprogramming in order to 
run more efficiently in the future. 

11.4 DATA CONVERSION PROCESSES 

A data conversion process takes data in one machine readable form and converts 
into another form. Data conversion lakes place during database creation, update, and in 
the schema-userschema mapping discussed earlier in this chapter. These processes are 
all members of a family of data conversion processes. 

Referring to Figure 11-9, a general data conversion process takes as input: 

• Existing mechanized data (in a database, an external file or a program buffer) called 

"source" data for the conversion process. 

• Its complete definition, which may be separate and explicit, may be buried in a spe- 

cial-purpose conversion program, or may be assumed in a general conversion 
program which expects the existing data to be in a prescribed format and 
structure. 

• The definition of the new ' 'target" data to be generated by the conversion process. The 

target data definition may be complete or it may be incremental to the source data 
definition. Also, the mapping between the two definitions may be completely 
implicit or partly explicit where the conversion process cannot infer the 
association. 

The conversion process produces as output: 

• A new collection of data (in a database, external file, or program buffer) which con- 

forms to the target data definition. 

11.4.1 The Family of Data Conversion Processes 

The family of data conversion processes includes mechanization, creation, update, 
revision, reversion.* and the schema to userschema conversion. These functions are 
shown in Figure 11- 10 as they relate within the family. For clarity, the source and 
target data definitions required of each conversion process are not shown. 

In a DBMS it is highly desirable for data conversion to be performed by the same 
underlying modules in the database control system. The availability of rich data con- 
version facilities in each of the members of the family of conversion processes deter- 
mine the degree of overall data independence exhibited in the system, thus contributing 

*Also called file writing or file generation (see section 7.1,3). 
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DATA STRUCTURES 



~ GROUPED ITEMS - record-based models 

- 3 constructs: - entity (entry or record) 

- attribute (daa item) 

- relationship 

— SINGLE FILE - data items grouped into one entry type 

- muttiplo such files may exist but the system knows 
no inter-file relationships (the users may) 



i SINGLE FLAT FILE 



- A single record type with 
single-valued data items 

- no repeating items or groups of it 



~j SIN 



GLE HIERARCHICAL FILE 



■ a single entry type containing 
nested repeating groups of items 
forming a multilevei structure 



- SINGLE PATH HIERARCHICAL STRUCTURE 
- one repeating group or 
record type at each level 



PERSON 



MULTIPATH ("BRANCHING") HIERARCHICAL STRUCTURE 
e.g., a COBOL file 



I ORG. UNIT I 



■j MULTIFILE STRUCTURE I - data items grouped into multiple entry types 
' - relationships defined between entry types (files) 

- some drop the term "file" and call this a "database" 

- each entry type (or "file") may have a flat 
or a hierarchical data structure (see SINGLE FILE) 



- HIERARCHICAL INTER-FILE RELATIONSHIPS - 1:Msny relationships only 
e.g., CODASYL, and Relational Data Model 



L. GENERAL INTER-FILE RELATIONSHIPS 

-1:1, 1 :Many, Many:Many relationships HEAD 



I ORG. UNIT I } 



^ UNIT 

PERSON ^ — ^ POSITION | 



UNGROUPED ITEMS - OBJECT- RELATION STRUCTURE 



- no prior grouping of 
items into record 

- 2 constructs: - object (entity or attribute) 
- relationship 

— BINARY RELATIONS BETWEEN OBJECT DOMAINS 



IRREDUCIBLE N-ARY RELATIONS BETWEEN OBJECT DOMAINS 
- each relation has at most one non-identifier item 



Figure 4-1, A Taxonomy of Data Structures. 
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Abstract: 

An improved Genetic Algorithm based on Evolutionarily 
Stable Strategy is proposed to optimize the initial weights of 
BP network in this paper. The improvement of GA lies in the 
introducing of a new mutation operator under control of a 
stable factor, which is found to be a very simple and effective 
searching operator. The experimental results in BP neural 
network optimization show that this algorithm can effectively 
avoid BP network converging to local optimum. It is found by 
comparison that the improved genetic algorithm can almost 
avoid the trap of local optimum and effectively improve the 
convergent speed. 

Keywords: 

Evolutionarily stable strategy; Genetic algorithm; Neural 
network; Back propagation (BP) algorithm; Premature 
convergence 

1 Introduction 

In recent years, there have been many attempts in 
designing artificial neural networks automatically, in which 
the combination of evolutionary algorithms and neural 
networks has attracted a great deal of attention and one kind 
of evolutionary artificial neural network has been formed. 
Evolving neural networks by genetic algorithm were 
researched earliest of all. 

The efficiency of GA has great influences on BP neural 
network (BPNN) optimization. During application of GA, 
however, there often exists a problem of premature 
convergence and stagnation "I Whitley think that selective 
pressure and selection noise are the main factors of 
affecting population diversity l2] . Higher selective pressure 
often leads to the loss of diversity in the population, which 
causes premature convergence at the same time of 
improving convergent speed. Therefore, keeping the 
balance between population diversity and convergent speed 
is very important to the performance of GA. 

In recent years, many diversity preservation methods 
have been developed to avoid premature convergence to a 
local optimum. These can be divided into the following 
three subclasses: 

1) Schemes of alleviating selective pressure to 
keep the biologic diversity, such as the modification of 
selection operator [3 " 51 and scale-transformation of fit 



function t61 . Unfortunately, these methods often cause 
another problem of slow rate of convergence or stagnation 
in searching global optimum at the same time of improving 
population diversity. 

' 2) Non- static mutation rate control schemes 
including dynamic r7_10] , adaptive or self-adaptive (,0 "' 2] 
mechanism to control the rate of mutation. The mutation 
operator is a maia operator to keep the biologic diversity, 
especially in reaj-coded GA, because it introduces new 
search space and maintain the genetic diversity of a 
population, whereas the crossover operator only operates in 
the known search space. From this point of view, high 
mutation rate is good for searching the global solution. But 
too high mutation rate will result in blind stochastic search. 
It has been proved that deterministically varying mutation 
rates during the search have a better performance compared 
to the fixed mutation rate schemes. Unfortunately, there are 
some drawbacks in non-static mutation rate control 
schemes. The dynamic parameter control scheme requires 
for the user to devise a schedule specifying the rate at 
which the parameter is typically decreased. The self- 
adaptive scheme does not need such a specific schedule. 
Unfortunately it in rather complicated to explain to novice 
users, and as a result they usually prefer the simple fixed 
mutation rate scheme. 

3)Spatial separation schemes [13 I4J . One of the 
most important lepresentatives is the distributed GA's 
(DGA's). Their premise lies in partitioning the population 
into several sub] populations, each one of them being 
processed by a GA independently of the others. 
Furthermore, a migration mechanism produces a 
chromosome exchange between the subpopuiatkms. In this 
way, a distributed search and an effective local tuning may 
be obtained simultaneously. They are suitable for producing 
multi-resolution in search space but run risk of running too 
much CPU time. 

A genetic algorithm based on evolutionarily stable 
strategy (ESSGA) is proposed in this paper to try to pursue 
better balance between population diversity and convergent 
speed by means of introducing a new kind of mutation 
operator under the control of a stable factor. Different from 
other mutation rate control schemes, this mutation operator 
only acts on some of the preponderant individuals under the 
control of a stable factor, which keeps the ratio of quantity 
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ABSTRACT 



Methods for estimating performance of and/or delecting 
faults in components of a multi-component system, where 
the performance of each component is defined by one or 
more performance parameters x related to measurement 
parameters z that can be expressed as a function of the 
performance and operating parameters defining an operating 
condition of the system. The methods include: defining a 
series of fault classes corresponding to possible outcomes of 
faulty components; creating an initial population of strings 
for each fault class, each including a plurality of elements 
corresponding to the performance and operating parameters, 
values being assigned to the string elements which represent 
estimated values of said parameters and are constrained only 
to indicate fault affected values for performance parameters 
of the fault affected component of the respective class; and 
optimising an objective function which gives a measure of 
/ between measured and calculated values of 
t parameters. 
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Art Unit: 2768 

No physical transformation is performed, no practical application is found. The claims appear to 
recite mathematical algorithms divorced from a practical application in the technological arts. 
The claims merely perform mathematical calculations in an expected manner as the machine is 
designed to do for any type of algorithm calculations, and present data results, add nothing more 
structurally or functionally than material falling under the non-statutory abstract idea concepts. 

Allowable sub ject 

5. As per claim 25, the prior art taken alone or in combination fails to teach or suggest for 
each value driver, multiplying each of the three numbers for capitalized value of future revenue, 
expenses, and changes in capital by the corresponding correlation percentage to yield a revenue 
value, an expense valued and a capital value taken in combination with a computer-implemented 
method for valuing one or more elements of a business enterprise on a specified valuation date. 

As per claim 38, the prior ait taken alone or in combination fails to teach or suggest 
calculating the value of a growth option using an option pricing algorithm taken in combination 
with a computer-implemented method for valuing one or more growth options of a business 
enterprise on a specified valuation date. 

As per claim 39, the prior art taken alone or in combination fails to teach or suggest 
combining results from step © and (d) in the copywitten Value Map format for display and 
optional printout taken in combination with a computer-implemented method of preparing a 
Value Map for a business enterprise on a specified valuation date. 
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As per claim 40, the prior art taken alone or in combination fails to teach or suggest an 
element valuation processor for calculating the value of each element by multiplying the 
capitalized values of future revenue, expenses and changes in capital by the correlation 
percentages and then summing the three resulting figures to yield the value of the element on the 
valuation taken in combination with a c system for valuing one or more elements of a business 
enterprise on a specified valuation date. 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Frantzy Poinvil, whose telephone number is (703) 
305-9779. The examiner can normally be reached on Monday through Thursday 
from 7:30 AM to 5:00 PM. 

The fax phone number for this Art Unit is (703) 305-0040. 

Any inquiry of a general nature or relating to the status of this application should 
be directed to the Group receptionist whose telephone number is (703) 305-3900-. 



6. 



Conclusion 



20Nov00 



Frantzy Poinuil 
Primary Examiner 
Art Unit 2164 
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09/761 ,671 - opinion appears to be based largely on an assumption that VBM is different than 
SVA in a number of areas where they are in fact the same (see pages 46 - 48). 
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Application 09/761,671 
Technology Center 3600 



Decided: August 29, 2007 



Before TERRY J. OWENS, HUBERT C. LORIN, and ANTON W. FETTING, 
Administrative Patent Judges. 

FETTING, Administrative Patent Judge. 

DECISION ON APPEAL 



STATEMENT OF CASE 

Jeffrey Scott Eder (Appellant) seeks review under 35 U.S.C. § 134 of a Final 
rejection of claims 69-103, the only claims pending in the application on appeal. 

We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6. 
We AFFIRM. 



Serial No.: 08/999,245 



61 



